During engineering, development, and testing of complex systems and devices, physical hardware (H/W) can be a limited resource. As such, it may not be possible for developers (e.g., scientists, engineers, software developers, and testers) involved in the development of such systems to have access to the physical hardware until very late in the development of the systems and devices. For example, the developers may be required to share a very limited number of prototypes or preproduction units of physical hardware until full production begins. As such, the developers may not be able to work in parallel. Rather, development and testing of the product may be delayed as each developer waits for their respective opportunity to access one of the available units.
The limited availability of physical hardware can be addressed using a desktop test environment (DTE), which may be a generic computing device (e.g., a personal computer) on which software of the physical hardware is hosted using an approach that modifies an Application Program Interface (API) layer of the software. In such approach, the DTE may use the same application software source code as the corresponding hardware device. However, the application software source code is rehosted to run on a PC host and compiled as an executable of a personal computer (e.g., desktop computer). In order to allow the hardware target software to run on a host personal computer the infrastructure software (e.g. drivers and board support package (BSP)) is removed and the API is modified to accommodate virtual I/O at the API layer to communicate with other simulations or emulations on the personal computer. This infrastructure software must be removed to rehost the software because some DTEs do not attempt to emulate several components of the physical hardware. The absence of these and other components can result in poor fidelity.
In testing situations, any problems related the missing components are unlikely to be discovered until the software is running on the physical hardware. For example, during integrated system testing, the various components may not operate as expected, even though testing had been performed using the conventional DTE. As a result, the application software may be revised and re-tested, which adds to the time and cost of development. Additionally, in cybersecurity applications, the missing components represents attack vectors that cannot be tested in the conventional DTE. Furthermore, in situations where the software has been recompiled for rehosting on the DTE, the resulting assembly language does not match the assembly language used in the physical hardware, which provides another potential attack vector that cannot be tested using the DTE.